[アップデート] EC2 Auto Scalingがインスタンスタイプ混在時の「インスタンスの重み付け」をサポートしました
みなさん、こんにちは! AWS事業本部の青柳@福岡オフィスです。
EC2 Auto Scaling が、インスタンスタイプ混在時の「インスタンスの重み付け (Instance Weighting)」をサポートしました。
Amazon EC2 Auto Scaling Now Supports Instance Weighting
「インスタンスの重み付け」とは?
今回のアップデートについて説明する前に、まず2018年11月のアップデートについておさらいします。
2018年11月アップデート「インスタンスタイプおよび購入オプションの組み合わせ」サポート
2018年11月に、EC2 Auto Scalingのアップデートとして「インスタンスタイプおよび購入オプションの組み合わせ」がサポートされました。
EC2のオートスケールが複数インスタンスタイプの混在指定に対応、廉価なスポット利用が実現しやすくなりました。 | Developers.IO
これは、Auto Scalingグループを作成する際に、オンデマンドインスタンスとスポットインスタンスを混在させたり、複数のインスタンスタイプを混在して指定したりすることができるというものです。
この時のアップデートでは、インスタンスタイプを混在させる場合には、例えば「Intel CPUタイプ」と「AMD CPUタイプ」の同じサイズのインスタンスタイプを混在させる (例:m5.large
とm5a.large
) といったことが想定されていました。
今回のアップデート「インスタンスの重み付け」サポート
今回のアップデートは、上記の「インスタンスタイプおよび購入オプションの組み合わせ」アップデートをより効果的に使用するためのアップデートとなっています。
「インスタンスの重み付け」とは、サイズの異なるインスタンスタイプに対して、サイズの比率に応じた「重み」を設定することです。
例えば以下のように設定します。
インスタンスタイプ | vCPU | メモリ | 「重み」 |
---|---|---|---|
m5.large | 2 vCPU | 8 GiB | 2 |
m5.xlarge | 4 vCPU | 16 GiB | 4 |
m5.2xlarge | 8 vCPU | 32 GiB | 8 |
そして、「インスタンスの重み付け」を指定する場合は、Auto Scalongグループのキャパシティが「インスタンスの数」ではなく「インスタンスの重みの総量」となります。
例えば、上記のように各インスタンスタイプの重みを設定した際に、グループのキャパシティを「12」に設定したとします。 その場合、Auto Scalingグループ内にプロビジョニングされるインスタンスのパターンの例は次のようになります。
これらのパターンは、それぞれインスタンスのタイプも数も異なりますが、いずれも「インスタンスの重みの総量」が「12」です。
つまり、サイズの異なるインスタンスタイプが混在している場合に、インスタンスの数を一定に保つのではなく、コンピューティングリソースの総量を一定に保とうという考え方です。
「インスタンスの重み付け」のメリット
では、このアップデートはどのような場面で使えるのでしょうか?
ここに、あるアプリケーションがあるとします。 このアプリケーションは、動作させるのに「vCPU=1 コア、メモリ=4 GiB」相当のコンピューティングリソースが必要です。 かつ、1台のEC2インスタンス上で同時に複数のアプリケーションを動作させることができます。
このようなアプリケーションであれば、条件さえ満たせば以下のように様々なタイプのインスタンスで動作させることが可能です。 (OSに必要なvCPU/メモリなどのオーバーヘッドは考えないものとします)
m5.large
: 2個のアプリケーションを動作させることが可能
m5.xlarge
: 4個のアプリケーションを動作させることが可能
m5.2xlarge
: 8個のアプリケーションを動作させることが可能
そこで、さきほどの「プロビジョニングされるインスタンスのパターン」に当てはめてみましょう。
どちらのパターンでも、合計「12個」のアプリケーションを動作させることが可能です。
コンピューティングリソースの総量を一定に保ちつつ「インスタンスタイプの混在」を可能にすることは、特に スポットインスタンス を利用する際にメリットとなります。
スペックあたりの単価が最も安価なインスタンスタイプを選択できたり、対象アベイラビリティゾーンにおいて特定のインスタンスタイプのスポットインスタンスが枯渇している場合であっても他のインスタンスタイプを選択できたり、柔軟にスポットインスタンスを利用することができるためです。
「インスタンスの重み付け」には、インスタンスタイプに応じてアプリケーションの配置を自動化したり最適化したりする機能はありません。
アプリケーションの配置については、必要に応じて別のAWSサービスやアプリケーション自身で実装する必要があります。
実際にやってみた
さて、前置きが長くなりましたが、実際に「インスタンスの重み付け」を指定してAuto Scalingグループを作成してみましょう。
Auto Scalingグループの新規作成を選択しましたら、最初のステップで「フリートの構築」の選択肢から「購入オプションとインスタンスを組み合わせる」を選択します。 これで、インスタンスタイプの混在と「インスタンスの重み付け」を設定することが可能になります。
続いて、「インスタンスタイプ」に使用するインスタンスタイプと「重み」の対応を入力します。 (「インスタンスタイプの追加」をクリックして必要な分だけ追加します)
「インスタンスの分散」の「次のデフォルトの設定を使用し、すぐに開始します」チェックボックスはチェックしたままでも構いませんが、チェックを外すとスポットインスタンス関連の設定を変更することができます。 (今回は「ベースを超えるオンデマンド割合」のみデフォルトから変更しています)
「グループサイズ」は、前述した通り「インスタンスの重みの総量」を指定します。
以降のステップは、これまでのAuto Scalingグループの作成手順と特に違うところはありません。
Auto Scalingグループを作成しましたので、プロビジョニングされたEC2インスタンスを確認してみます。
今回は、m5.large(重み2)
のインスタンスが8個、m5.xlarge(重み4)
のインスタンスが1個、起動されました。
インスタンスの「重み」の総量は、指定したキャパシティの通り「20」になっています。
(これらのインスタンスが「オンデマンド」「スポット」のどちらで作成されたのかも参考までに掲載しておきます)
今回の結果 (インスタンスタイプの組み合わせと数、オンデマンドとスポットの割り当て) は、今回たまたまこのようになっただけで、毎回このようになる訳ではありません。
また、インスタンスタイプの組み合わせと数、オンデマンドとスポットの割り当ては、Auto Scalingグループを運用していくことによって変化していきます。
(例えば、スポットインスタンスの「中断」の発生によって1台の m5.xlarge
インスタンスが停止した際、代わりに2台の m5.large
インスタンスが起動する、など)
おわりに
今回のアップデートは、アプリケーションの作りやスケーリング要件などによって、利用できる場面を選ぶのではないかとは思われます。
ただし、「ハマれ」ば効率よくスポットインスタンスを利用できることになりますので、検討してみる価値はあるのではないでしょうか。
個人的には、ECSやEKSなどコンテナ環境に向いているのではないかと思いました。 機会があればECS、EKSと「インスタンスの重み付け」の組み合わせを試してみたいと思います。